Guarantee alignment of fixed-width integer primitives#2205
Guarantee alignment of fixed-width integer primitives#2205joshlf wants to merge 4 commits intorust-lang:masterfrom
Conversation
rustbot
added
the
S-waiting-on-review
traviscross
added
T-lang
|
Thanks. I pushed a clarification and separated out the rules. Clearly we want to guarantee this for fixed-width integers of the same size. @rfcbot fcp merge lang |
|
Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
src/type-layout.md
Outdated
| The alignment of primitives is platform-specific. In most cases, their alignment is equal to their size, but it may be less. In particular, `i128` and `u128` are often aligned to 4 or 8 bytes even though their size is 16, and on many 32-bit platforms, `i64`, `u64`, and `f64` are only aligned to 4 bytes, not 8. | ||
|
|
||
| r[layout.primitive.integer-alignment] | ||
| Alignment is guaranteed to be the same for signed and unsigned integer variants of the same size --- that is, for a given size `N`, `align_of::<uN>() == align_of::<iN>()`. |
There was a problem hiding this comment.
I would reword "of the same size" to something else. otherwise it sounds like u64 and usize must have the same alignment on 64-bit platforms.
There was a problem hiding this comment.
Alignment is guaranteed to be the same for fixed-width signed and unsigned integer variants of the same indicated size --- that is, for a given size
N,align_of::<uN>() == align_of::<iN>().
How about that?
There was a problem hiding this comment.
Did you want to cover usize/isize too?
There was a problem hiding this comment.
What about this?
The following pairs of types have the same alignment:
- u8 and i8
- u16 and i16
- u32 and i32
- u64 and i64
- u128 and i128
- usize and isize
There was a problem hiding this comment.
What about this?
The alignment of primitives is platform-specific. In most cases, their alignment is equal to their size, but it may be less. In particular,
i128andu128are often aligned to 4 or 8 bytes even though their size is 16, and on many 32-bit platforms,i64,u64, andf64are only aligned to 4 bytes, not 8.Furthermore, it is guaranteed that:
- u8 and i8 have the same alignment.
- u16 and i16 have the same alignment.
- u32 and i32 have the same alignment.
- u64 and i64 have the same alignment.
- u128 and i128 have the same alignment.
- usize and isize have the same alignment.
There was a problem hiding this comment.
Probably at that point, then, I wonder whether we should be revising the table above to include this somehow rather than reiterating all of the the primitive types again.
There was a problem hiding this comment.
Did you want to cover usize/isize too?
Those are covered in #2200.
The purpose of the existing `layout.primitive.align` rule is to state that the alignment of primitives is platform-specific. Adding a separate alignment guarantee for integers overloads this a bit. Let's instead separate out the rules; we'll rename the existing rule since there are now two rules speaking to alignment.
Let's make this wording a bit more clear, and let's fix the em dash to use `---` since that's what our renderer expects.
5 participants
Follows up on #2200 (comment)
As an optional extension, we could consider guaranteeing equality between the alignments of:
u32andcharu32andf32u64andf64Those equalities strike me as less important, and I'm not sure if they're even valid (ie, whether they hold on all platforms).